On most computer networks, bits of data arranged in bytes are packaged into collections of bytes called packets. These packets are generally communicated between computing devices over networks in a wired and/or wireless manner. A suite of communication protocols is typically employed to communicate between at least two endpoints over one or more networks. The protocols are typically layered on top of one another to form a protocol stack. One model for a network communication protocol stack is the Open Systems Interconnection (OSI) model, which defines seven layers of different protocols that cooperatively enable communication over a network. The OSI model layers are arranged in the following order: Physical (1), Data Link (2), Network (3), Transport (4), Session (5), Presentation (6), and Application (7).
Another model for a network communication protocol stack is the Internet Protocol (IP) model, which is also known as the Transport Communication Protocol/Internet Protocol (TCP/IP) model. The TCP/IP model is similar to the OSI model except that it defines four layers instead of seven. The TCP/IP model's four layers for network communication protocol are arranged in the following order: Link (1), Internet (2), Transport (3), and Application (4). To reduce the number of layers from seven to four, the TCP/IP model collapses the OSI model's Application, Presentation, and Session layers into its Application layer. Also, the OSI's Physical layer is either assumed or is collapsed into the TCP/IP model's Link layer. Although some communication protocols may be listed at different numbered or named layers of the TCP/IP model versus the OSI model, both of these models describe stacks that include basically the same protocols. For example, the TCP protocol is listed on the fourth layer of the OSI model and on the third layer of the TCP/IP model. Additionally, the HTTP protocol is listed on the seventh layer of the OSI model and on the fourth layer of the TCP/IP model.
To assess and troubleshoot communicated packets and protocols over a network, different types of network monitors can be employed. In some instances, a network monitor may operate as a proxy that is actively arranged between two endpoints, such as a client device and a server device. A network monitor proxy intercepts each packet sent by each endpoint and retransmits or forwards each intercepted packet to the other endpoint. Since network monitor proxies actively monitor network packets, they often enable a variety of additional services such as caching, content filtering, and access control.
Another type of network monitor, a “packet sniffer” may be employed to generally monitor and record packets of data as they are communicated over a network. Some packet sniffers can display data included in each packet and provide statistics regarding a monitored stream of packets. Also, some types of network monitors are referred to as “protocol analyzers” in part because they can provide additional analysis of monitored and recorded packets regarding a type of network, communication protocol, or application.
Generally, packet sniffers and protocol analyzers passively monitor network traffic without participating in the communication protocols. In some instances, they receive a copy of each packet on a particular network segment or VLAN from one or more members of the network segment. In other instances, they may receive these packet copies through a port mirror on a managed Ethernet switch, e.g., a Switched Port Analyzer (SPAN) port, or a Roving Analysis Port (RAP). Port mirroring enables analysis and debugging of network communications. Port mirroring can be performed for inbound or outbound traffic (or both) on single or multiple interfaces. In still other instances, packet copies may be provided to the network monitors from a specialized network tap. However, in some situations the network monitor may not receive copies of packets that are transmitted between endpoints, thus creating a hole.
Holes can be a common occurrence with passively monitoring flows of packets, which may, in some situations, result in a monitoring device being put into a desynchronized state. Without the ability to resynchronize, the monitoring device may miss a lot of information transmitted between endpoints. This may be especially true with long-lasting flows. It is with respect to these considerations and others that the present invention has been made.